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FOREWORD 

This Indian Standard (Part 6) was adopted by the Bureau of Indian Standards, after the draft finalized by the 
Management and Productivity Sectional Committee had been approved by the Management and Systems Division 
Council. 

The prime objective of production control is to help a company become more competitive and profitable. 
An effective production control function endeavours to fulfil this objective by keeping a balance between 
satisfying sales demand, achieving high plant utilization and maintaining low investment in stocks and 
work-in-progress. An optimum balance between these often conflicting objectives will only be achieved by 
a production control system designed to meet the specific needs of the company and run by well trained and 
dedicated staff. 

The planning and information flows in the various stages of a production control system {see Fig. I) can be 
facilitated by the use of computers. This standard describes the benefits of the use of computers in the production 
control process. The capabilities of computers to store, maintain, manipulate and share large volumes of data and 
communicate information very quickly is ideally suited to the present day needs of production control. Today's 
manufacturer can be faced with international competition, quickly changing markets, the customer's expectation 
of significant reductions in design-to-delivery lead times and severe profit margin erosion. Much of this pressure 
is brought about by the intelligent use of computers by the competition especially in the field of production 
control. The effective management of this area of the business is vital and can lead to significant cost reductions 
in the areas of work in progress and component stores; it can also lead to an overall reduction in delivery lead 
time. 

To remain viable and to meet and beat the competition, manufacturers should seriously evaluate the use of 
computer aids in production control. This evaluation has to be professional in terms of the objectives and the 
likely costs and benefits. The effort required is large and cannot be taken lightly, but the rewards in terms of 
improvements in performance and management control can be enormous. 

NOTE — The development of the use of computers in production control is described in Annex A. 

Reference has also been made to following British Standards for which there are no Indian Standards: 

BSNo. Title 

3138: 1992 Glossary of terms used in management services 

5191 : 1 975 Glossary of production planning and control terms 

The concerned Sectional Committee has reviewed the provisions of these British Standards and has decided that 
they are acceptable for use in conjunction with this standard. 

While formulating this standard, considerable assistance has been taken from BS 5192 (Part 6) : 1993 'Guide to 
Production Control: Part 6 Computer aided production control'. 

This standard is published in six parts and gives comprehensive guidance in those areas that are considered 
essential for effective production control. The other parts in the series are as follows: 

/SA'o. Title 

15446 Guide to production control: 

(Part 1) : 2004 Introduction 

(Part 2) : 2004 Production programming 

(Part 3) : 2004 Ordering methods 
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1 SCOPE 

This standard (Part 6) gives guidance on the use of 
computers in production control. It does not describe 
the use of computers in other areas of the business 
such as computer aided design, engineering 
management, finance, purchasing, payroll, 
maintenance and sales order processing. However, the 
techniques and requirements identified and 
recommended in this standard for the establishment 
of a formal specification of requirement, selection and 
justification of a computerized production control 
system (either bespoke or a commercial package), 
installation and implementation of the system, together 
with the guidance on on-going operational 
requirements and future trends, may be applicable not 
only to production control systems but equally to the 
professional evaluation, selection implementation and 
operation of any business system in the manufacturing 
company. 

2 REFERENCES 

The following Indian Standards contain provisions 
which, through reference in the text, constitute 
provisions of this standard: 



IS No. 
15446 

(Part 1): 2004 
(Part 3) : 2004 



Title 
Guide to production control: 
Introduction 
Ordering methods 



3 DEFINITIONS 

For the purpose of this standard, the definitions given 
in IS 15446 (Part 1) shall apply. 

4 SPECIFICATION OF REQUIREMENTS 

4.1 Business Requirements 

4.1.1 In today's business environment of international 
competition, world class quality for products and 
drastically reducing manufacturing lead times, the need 
for good production control systems has to be clearly 
understood in terms of the business requirements. 
These should be defined clearly in three strategy 
statements. 

a) Marketing strategy of the company — It 
should be stated what segments of the market 
the company is in, what segments it is not in 
and where the company plans to be in 5 to 1 
years. 



b) Business strategy — The business and 
financial targets that the company has set for 
itself over the next 5 years should be stated. 
Examples are return on investment targets, 
inventory turns, production lead times, quality 
targets, cost reduction targets, profitability 
targets, training targets, market share by 
country. 

c) Information technology strategy — The types 
of systems that will be required to meet the 
demands of the business and marketing 
strategies in the face of competition should 
be identified. 

4.1.2 After the business, marketing and information 
technology strategy statements are known and agreed 
within a company, the informational subset that is now 
required to support the production control part of the 
business can be defined. 

4.2 Problem Definition 

Once the business, market, and information technology 
objectives have been established, the problem for 
production control is to define how to achieve them. It 
is necessary to identify the main problems that have to 
be overcome in the production control function to 
support these strategies and at the same time fit into 
the overall framework of present and future system 
communication requirements implied by the strategies. 
The problem definition phase should describe the 
production problems in terms of the following 
requirements: 

a) Batch sizes; 

b) Routeing options; 

c) Contract control; 

d) Traceability; 

e) Frequency of change over; 

f) Work-in-progress value; 

g) Engineering change control; 
h) Bottlenecks; 

j) Overall manufacturing lead time objectives; 

k) Quality/rework objectives; 

m) Volume; 

n) Warranty control; 

p) Key equipment maintenance; 

q) Multi-site manufacturing; 
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r) Centralized or decentralized purchasing; 
s) Centralized or decentralized production 

planning and control; 
t) Cost of space; 
u) Cost of people skills; and 
v) Space constraints. 

'Hie objective here is to define the production control 
problems that are specific to this business and then 
prioritize their importance. 

4.3 Functional Requirements Specification (FRS) 

4.3.1 After the objectives have been established and 
the specific problems defined, a functional 
requirements specification (FRS) should be drawn up. 
This step is absolutely crucial and cannot be ignored. 
U establishes the basis for the system design and 
provides the reference point for comparing all proposed 
solutions (whether in-house or third party). 

4.3.2 Without this vital reference point the evaluation 
of all possible solutions is haphazard and 
unprofessional. Without it there is a risk of comparing 
one solution against another rather than always 
comparing a proposed solution against an agreed 
standard (the FRS). In the case of purchasing computer 
software, shopping around for a solution is useless 
without the agreed specification against which to 
compare it. The FRS has to be agreed formally by the 
major business divisions within the company such as 
Unance, manufacturing, sales/marketing, engineering 
and data processing. Otherwise the resulting solution 
will not be used seriously by the end users. 

4.3.3 The FRS should describe in the detail the flow of 
information required, the volumes anticipated and the 
business issues to be serviced. For example the 
following sizing requirements may be specified: 

a) Number of parts; 

b) Number of product structures; 

c) Number of operations; 

d) Need for alternative structures and routeings; 

e) Contract control requirements; 

f) Traceability requirements; 

g) Batch sizes; 

h) Quality control targets; 

j) Shop-floor data collection requirements; 

k) Finite scheduling requirements; 

m) Capacity modelling; 

n) Master scheduling modelling; 

p) Re-order levels; 

q) Material requirements planning (MRP) 

capabilities; 

r) Links to cell controllers; and 



s) Links to other business systems such as: 

1) Accounting/finance/ledgers 

2) Purchasing 

3) Finished goods 

4) Receiving 

5) Engineering/design 

6) Sales orders 

7) Sales forecasts. 

4.3.4 The objective of the functional requirements 
specification is to think through and address in detail 
the type and flow of information required to support 
the business problems. The actual systems required to 
implement the specification range from face to face 
verbal communication in a small partnership to large 
scale integration in very large companies. However, 
without the agreed specification a detailed computer 
software solution (if required) cannot be designed. 

4.4 Feasibility Study 

4.4.1 Once an agreed functional requirements 
specification has been obtained, the feasibility of the 
alternative solutions should be examined so that a 
recommendation can be made. At this stage the 
feasibility of manual systems, bespoke software, 
commercial software, or the combined use of two or 
all three of these is evaluated. 

4.4.2 Manual systems are most effective when volumes 
are low and the timeliness of data is not critical. 
However, manual systems still require documented 
procedures and controls. 

4.4.3 If part of the solution deemed appropriate to 
address the functional requirements definition of 
production control is computer based, there are two 
options: develop a bespoke production control system 
in-house or using a third party; or find a commercially 
available product that has a reasonable fit to the 
requirements. The best fit will always he from a system 
specifically designed and programmed for the defined 
requirements. However, this is a costly and time 
consuming task even with the use of the most modern 
development tools. The costs are in two areas: 

a) Development of a system requirement 
specification that is a detailed computer 
specific specification; 

b) Development of a system design specification 
that is a detailed code level specification. 

There is an associated cost and talent requirement for 
each of these plus the on-going maintenance and error 
correction support costs of the finished product. 

4.4.4 Bespoke systems provide the best fit but they are 
usually not undertaken because of the huge overhead 
costs in developing and maintaining b one-off system. 
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The usual compromise is to find a commercial product 
which is a close fit (80 percent is satisfactory) and either 
to modify the last 20 percent in agreement with the 
vendor or to modify the company procedures to fit the 
standard. The benefits of commercially available 
systems are: 

a) On-going maintenance and development; 

b) Error correction support; and 

c) Consultancy and training availability. 

4.4.5 It is the function of the feasibility study to 
evaluate these options and to choose the most cost 
effective direction. 

4.5 Market Appraisal 

if the recommendation of the feasibility study is to 
utilize a commercial software product, a market 
appraisal may be necessary to find the best solution. 
This is where the FRS is particularly valuable and forms 
the basis for the capability evaluation. This view, 
balanced with system costs, return on investment 
views, software availability, adherence to system 
standards, financial health of the vendor and total 
system cost of ownership including hardware and 
supporting system software, will enable the company 
to make a product/vendor selection. 

4.6 Computer Software Definition 

An important aspect of the computer based solution is 
its ability to coexist with and link into other existing 
and proposed systems. Therefore, the standards which 
the company wishes to utilize in support of their 
objectives should be defined first. Areas to be 
considered are as follows: 

a) Communication standards; 

b) Database structure to be used; 

c) Programming language to be used; 

d) Operating system standard; and 

e) Security and access control. 

4.7 Computer Hardware Definition 

A further definition of the system standards the 
company requires may be appropriate for the hardware. 

Considerations are: 

a) Need for colour graphics; 

b) Remote communication; 

c) Speed of transaction response; 

d) Maintenance and training costs; 

e) Use of standard packages on the hardware; 

f) Programming language availability; and 

g) Vendor's financial health. 



5 OPTION SELECTION OF STANDARD PACK AG ES 
5.1 General 

5.1.1 For each new system introduction it is essential 
to study the specification of requirements outlined 
in 4. After the functional requirements specification 
{see 4.3) has been completed a key decision should be 
made: whether the functionality defined can be 
obtained by using a standard package or whether it 
will be necessary to develop a bespoke system. 

5.1.2 The development of a bespoke system or indeed 
a major tailoring of a standard system is a costly and 
time consuming route. It is therefore recommended that 
companies should re-examine the requirement for the 
functions not provided by a standard package and 
check whether there is an alternative standard function 
that would fulfil the same need. They should also 
question whether that function is essential or just 
attractive and whether the extra cost and time of 
implementing it would be justified. 

5.1.3 A distinction should be drawn between the 
incorporation of a new function and changes to the 
input and output screens and forms. The latter case, in 
general, will be relatively easy to amend to meet users' 

preferences. 

5.1.4 In 5.2 to 5.4 some of the main categories of 
application package which might be considered for use 
within a manufacturing company are outlined. For each 
category there is a brief description of: 

a) Major functions that would be expected in a 
standard package; 

b) Areas and industries where the category of 
package is generally applied; and 

c) Possible problems and an indication of how 
an improved solution can be achieved. 

5.1.5 An application package will usually consist of a 
number of modules. Annex B lists the major package 
modules and the functions typically found in them. 
Additional modules are also available to handle specific 
manufacturing requirements and those of other parts 
of the company. To be effective all these should be 
integrated, so that users have the minimum of 
inconvenience in switching between modules and 
duplicated data entry is avoided. 

5.2 Stock Control Application Packages 

5.2.1 General 

Applications for stock control are usually one of the 
following two types: 

a) Those that are made up of modules (for 
example part data, purchasing, inventory 
control) that interlink and to which further 
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modules can be added as required (for 
example financial, planning); and 
b) Those that are not modular but carry out 
similar functions; such applications often 
have more sophisticated statistical control and 
reporting features. 

5.2.2 Major Functions 

Stock control application packages enable users to 
control the stocking and replenishment of materials. 
Users maintain a database of stock item information 
and the quantity of stock on-hand. The usage of stock 
is recorded and forecasting techniques may be used to 
predict future usage and hence when or how much to 
re-order to prevent stockout. The re-order decision may 
be based on the following: 

a) Fixed order quantity [see 6.3 of IS 1 5446 
(Part 3) : 2003]; 

b) Fixed interval re-order [see 6.4 of IS 15446 
(Part 3) : 2003]. 

Re-order recommendations may be handled by a 
purchase order module. 

5.2.3 Application Areas 

This type of package may be suitable for companies 
or departments that buy and re-sell goods, or use 
material with no or minimal processing. Examples 
might be those engaged in maintenance, spares or retail 
activities. 

5.2.4 Possible Problems 

The following aspects of stock control application 
packages may cause problems. 

a) Production control — The basic stock control 
functions are not supplemented by any 
planning function. Therefore, any associated 
manufacturing activity is not planned or 
controlled. These functions are left to manual 
procedures or stand-alone systems. 

b) Priority control — The due-date of the orders 
is assigned at the re-order point (ROP) or the 
review point, but the standard functions do 
not revise the due-date with changing events. 
The tendency is therefore to expedite the 
urgent requirements but not de-expedite the 
non-urgent. This rapidly destroys any priority 
for interna! or external supply orders. 

c) Dependent demand — Where any 
conversion, process or treatment is carried 
out on a raw material to turn it into a product, 
then the demand for that raw material is 
dependent on the requirement for the 
product. It is therefore unnecessary to 
forecast the raw material demand. 



Companies that do so run the risk of a change 
in product requirement pattern causing 
shortage or excess of the raw material. 

d) Item parameters — Each item is replenished 
according to certain key parameters, for 
example, lead time, order quantity, safety 
stock, forecast mean, trend and seasonality. 
Maintaining all these parameters is a major 
task that is often overlooked, with the result 
that external information is not incorporated. 
System calculated parameters also need 
to be examined frequently to ensure the 
assumptions within the calculations are 
correct. 

e) Forecasting — Predicting future usage on 
the basis of past history will never be perfect. 
It should be supplemented by extrinsic 
knowledge that is industry trends, marketing 
plans, etc. However, sophisticated systems 
can vary the calculation according to the 
pattern of demand, for example, steady, 
lumpy, rising or falling trend. This may be 
done automatically or by user decision. Users 
should ensure that demand pattern changes 
are identified as early as possible and 
appropriate action is taken. 

5.3 Manufacturing Resource Planning (MRP II) 
Application Packages 

5.3.1 General 

Application packages for manufacturing resource 
planning (MRP II) are, almost without exception, made 
up of a number of modules that are selected to suit the 
specifrc environment in which they are to be used. The 
major modules are listed in annex B. However, total 
systems can often also link to modules such as financial 
ledgers, computer aided design (CAD), computer aided 
manufacturing (CAM), payroll, distribution, automated 
guided vehicles (AGV) control, contract costing, sales 
order processing and shop-floor data collections that 
are outside the scope of this standard. 

5.3.2 Major Functions 

Application packages for MRP 11 enable users to plan 
and control the materials, people and machines in a 
company at three or four levels. Users maintain 
databases of information on the parts, the bills of 
material, the routeings, the work centres and the 
vendors. There are facilities to plan the major resources 
of the company and to master schedule the existing or 
forecast orders well into the future. When these orders 
and resources are in balance the material requirements 
plan is generated, giving recommendations on orders 
that should be placed, amended or cancelled at all 
planning levels of the bill of material (BOM). 
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Manufacturing orders are then routed through the 
factory to generate work-to-lists and capacity loading. 
Purchase orders may be placed and tracked. Materials 
and manufacturing order movements are recorded and 
the plan at each level is kept valid by feedback of 
information and management action. 

5.3.3 Application Areas 

MRP 11 packages have been used successfully in a very 
broad range of manufacturing business ranging from 
pure process type, through high volume repetitive to 
job shop and design-to-order businesses. The standard 
core system modules are listed in Annex B. They may 
be supplemented to suit particular environments. Each 
module should have alternative options that enable it 
to be used effectively in virtually any market or 
manufacturing styple. 

5.3.4 Possible Problems 

Despite its widespread acceptance as the standard 
approach to planning and control of manufacturing, 
alarmingly few of the implementations realize their full 
potential to help the company achieve its strategic 
objectives and some do not even repay their 
investment. It is therefore, important to examine 
carefully the problem areas and reason for failure to 
ensure that mistakes are not repeated and that an 
implementation produces maximum benefits. Some 
common difficulties are as follows: 

a) Capacity control — Because the standard 
'back schedule to infinite capacity' 
assumption is used by MRP II systems, users 
may be tempted to overload the factory. This 
should be avoided by proper use of the master 
production schedule (MPS)/rough-cut- 
capacity planning (RCCP) modules which 
plan resources in the longer term and validate 
forecast input and order intake. Short-term 
contention may still occur, but can be reduced 
by use of capacity requirements planning 
(CRP) to smooth the load or to re-route 
problem orders. 

b) Data accuracy — The most common cause 
of poor performance is that the data in the 
system are insufficiently accurate to persuade 
users to believe in what they see presented 
on the visual display unit (VDU). An audit of 
stock balances, routeings and live orders 
should be carried out before the system is 
introduced and corrective action programmes 
put in hand. The main system should not be 
run until the following minimum standards 
are attained: 

i) inventory accuracy > 95 percent; 



ii) BOM accuracy > 98 percent 
iii) routeing accuracy > 98 percent 

c) Overdue orders — Any order not completed 
on time is deemed to be overdue. Such orders 
fall into backlog on the resource and capacity 
plans. As a result the priority of orders 
becomes confused, particularly when some 
overdues are no longer live (if, for example, 
the vendor considers 90 percent is completed 
or the shop-floor has scrapped the laat 5 
percent). Overdue orders should be checked 
regularly, and if live, re-dated to a real future 
date that is achievable. 

d) Expediting — Some expediting will always 
be needed in the real world to maintained 
delivery schedules. However many 
companies expedite for the wrong reasons (for 
example, the operator to select the easy orders, 
the foreman to keep his men busy, the 
manager to achieve high shop efficiency, 
directors to meet non-business objectives). 
The only valid expediting is that necessary to 
maintain the work-to-list priorities; all others 
should be strongly discouraged. 

e) Complexity — A fu II function M RP 1 1 system 
offers a staggering number of options and 
parameters. It can also encourage design 
engineers to input an as-designed BOM rather 
than the as-produced. Likewise planning 
engineers may over-complicate the routeings. 
All elements of added complexity require 
extra feedback and maintenance activity. 
Often this is not worthwhile and is not done 
satisfactorily, thus bringing the system into 
disrepute. Users should aim for the simplest 
solution that meets their needs. 

f) Function frequency — The major functions, 
for example, reviewing the MPS, running 
MRP and revising the work-to-iists, should 
be done at a frequency to suit the business. 
Typically this means MPS review monthly, 
MRP nightly and work-to-list hourly or in real 
time. Fast moving environments may need 
MPS and MRP more frequently. Users and 
systems operators should be educated to 
understand and plan how to meet the 
necessary frequency. 

5.4 Finite Capacity Scheduling Application Packages 

5.4.1 General 

Applications for finite capacity planning are usually 
provided as complete packages running on a personal 
computer or workstation that interlinks to 
manufacturing control and shop-floor data collection 



IS 15446 (Part 6): 2004 



systems. Use of a personal computer provides the 
highly interactive, graphical environment which the 
scheduling/planning function requires. 

5.4.2 Major Functions 

These applications enable users to control, on a minute- 
by-minute basis, the allocation of jobs and operators 
to machines, thereby permitting a plan of short-term 
workshop activity to be created. Users maintain a 
database of individual resources, resource groupings 
and characteristics, shift patterns and non-worked days. 
The package produces a schedule that may be passed 
back to the production control system and/or issued in 
the form of work-to-lists, to machine operators on shop 
supervision. The main functions of the scheduler are: 

a) an electronic planning board using a computer 
graphics system; 

b) an ability to communicate with other 
computer systems; 

c) a database to store shift patterns, resource 
data, etc; 

d) an ability to schedule operations 
automatically to pre-defined criteria; and 

e) an ability to manipulate the plan manually. 

5.4.3 Application Areas 

This type of package is suitable for companies in a 
wide range of manufacturing environments, including 
jobbing, process industry, batch and mass production. 
However, different suppliers' packages are focused on 
different industries and this will be reflected in the 
facilities offered. 

5.4.4 Possible Problems 

The following aspects of MRP II application packages 
may cause problems. 

a) Flexibility — The scheduling package should 
be capable of dealing with the special 
constraints of the company's method of 
operation; 

b) Accuracy — The scheduling package should 
be capable of reflecting the true position of 
shop-floor operations. The scheduler needs 
accurate, up-to-date information to make 
valid decision on job allocation. These data 
are best obtained from a shop-floor data 
collection or machine monitoring system; 
and 

c) Horizons — The horizon for a finite 
scheduling package should be relatively short, 
say one week. Extended horizons make it very 
difficult to synchronize material supplies. The 
schedule will also tend to become unstable. 



6 BESPOKE SYSTEMS 

6.1 General 

6.1.1 Companies often find that the standard packages 
available do not fully meet the full range of functions 
they believe they require. If this is so they should decide 
whether to compromi.se on their needs, tailor the 
package or build their own bespoke system. The 
decision has major implications in terms of cost, time 
and usability and should therefore be taken after careful 
consideration of all the facts and by using specialist 
outside skills to supplement in-company knowledge 
where necessary. 

6.1.2 The standard package option is always the fastest 
and cheapest and will generally provide many of the 
core functions. As a rule of thumb it is recommended 
that if a significant proportion of the functions are 
present then tailoring is the best solution. However, if 
several essential functions are absent, then bespoke 
system development is indicated. 

6.2 Full System Development 

6.2.1 This solution will take time (one to three years) 
and a considerable degree of user involvement and will 
be^xpensive. It will consist of a phased development 
covering the following typical stages. 

a) Computer systems design — converting the 
functional requirements specification into 
database and system specifications covering 
reports, screens, file updates and data 
maintenance; 

b) Technical specification — based on the 
computer system design, making a decision 
on the technical environment in which the 
programmes will run (database, development 
language, on-line teleprocessing, networking 
etc); 

c) Programme and system test — converting the 
computer system design into a computer 
programme based on decisions made in the 
technical specification and testing individual 
modules; 

d) User acceptance test — testing the whole 
system with real data; 

e) Installation — loading the programmes and 
live data, initializing the system, training 
users, running parallel and going live; 

f) Evaluation — comparing results with those 
required and tuning both the technical and 
functional performance; and 

g) Maintenance — changing functionality to 
meet new needs. 

6.2.2 A major requirement for the successful outcome 
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from the development is strong, final result orientated, 
project management to control budgets, timescales and 
user expectation. 

6.3 Tailoring Standard Packages 

6.3.1 Most companies will have their own needs for 
the form of the data presented on a VDU or report and 
in the way they want it laid out. For instance the 
following information may be displayed together with 
the user field name: 

a) Company specific headings, titles and field 
names may be required; 

b) Some companies may wish to have a field 
such as cost displayed, others may not; 

c) Dates may be required in one of many 
formats; and 

d) The result of calculations on database. 

6.3.2 Changes of these types may be accomplished by 
the following different methods: 

a) Source code amendment — This type of 
change may be made by the user only if the 
source code is available and the user is skilled 
in the programming techniques and language 
used. This is the subject of bespoke 
amendments and is not usually termed 
tailoring. It should not be attempted without 
careful system planning and control (5ee9.5); 

b) Fourth generation language (4GL) — 4GLs 
are becoming increasingly user friendly and 
can provide a very high degree of screen and 
report output io the format required by the 
user. However the ease and flexibility of use 
are very dependent both on the 4GL and on 
the database structure of the main production 
control software. A high level of user training 
may be required to use the advanced tailoring 
available. New applications developed with 
4GLs are likely to need full bespoke system 
management techniques; and 

c) Screen/report generator — Many 
manufacturing planning and control packages 
include a facility for amendment of the screens 
and reports of the standard system. The 
flexibility will depend on the particular 
package and should be checked by users for 
the presence of functions to achieve the degree 
of tailoring they require. They may be used by 
company staff trained by the software vendor 
but changes should be documented and 
monitored by the system department. 

6.4 Advantages and Disadvantages of Bespoke 
Systems 

6.4.1 The obvious advantage of a bespoke system is 



that it should deliver exactly what the user needs to do 
the job. The obvious disadvantage is that it takes time, 
people and money. A bespoke system can be justilled 
if it does provide the correct solution. Experience 
shows that there are many pitfalls and that many 
bespoke systems fail to provide the answer to real 
problems of the company and overrun on time and cost. 
Examples of the hazards include the following: 

a) Incorrect understanding of the real problems; 

b) Computerizing old procedures, not new 

needs; 

c) Trying to automate human judgement 
functions; 

d) Not subdividing activities sufficiently to 
enable them to be controlled; 

e) Under-resourcing the project (in volume and 
quality); 

f) Changing requirement after FRS; 

g) Allowing timescales and budgets to slip 
without investigation and corrective action; 

h) Poor documentation; 

j) Incomplete testing; 

k) Inadequate user education and training; 

m) Lack of qualitative and quantitative 

evaluation; 

n) Poor modification control; and 

p) Lack of senior management commitment. 

6.4.2 Nevertheless, bespoke projects that are well 
managed can provide outstanding benefits providing 
the critical factors of time, cost and effectiveness are 
uppermost in the project manager's mind. 

7 SYSTEM SELECTION AND JUSTIFICATION 

7.1 General 

Assuming the feasibility study has recommended the 
use of a computerized production control system, the 
system required should now be found and the business 
case approved. 

7.2 Software Evaluation 

7.2.1 The FRS will be used as the evaluation yardstick 
for software. Because the FRS will be long and 
complex, a checklist of all the features in priority 
sequence should be created and agreed. This list should 
have cut-off lines drawn through it between the 
essentia! functions, the desirable functions, and the 
attractive features. As a starting point this one page 
list can be used to begin the elimination process. 
However, since functional requirements are onlv one 
of three major selection criteria, the checklist should 
be a composite of the specifications from the FRS, 
hardware and software requirements identified in 4.6 
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and 4.7 (including the communication issues) and the 
cost/return-on-investment specifications. Therefore, if 
MRP II is an essential requirement for the functionality, 
but the total system cost has to be under £250 000 and 
be on an open operating system (and these are also 
essentials) the requirements of the FRS are 
considerably limited by the other two requirements. A 
consolidated requirements list like this can be generated 
by the company through its own resources or produced 
on the company's behalf by a third party professional 
consultancy team. 

7.2.2 After the initial elimination list has been produced 
the products to be evaluated should be found. For 
production control software the problem will be one 
of choosing from a large list of options. Sources of 
information on software availability can be obtained 
directly from the major hardware vendors, from the 
major software houses and from trade shows. 

7.2.3 Once a short list of software has been agreed it is 
now time to inspect each in detail against the original 
and full functional specification. Final selection will 
then be based on further additional criteria such as the 
following: 

a) Feature availability; 

b) Fit to specification; 

c) Consultancy and training availability; 

d) Maintenance cost and availability; 

e) Software stability and availability; 

t) Ability to communicate with other systems; 

g) Ability to expand; 

h) On-going commitment from vendor for 

development; 

j) Ease of use; 

k) Response time; 

m) Similarity to present system; and 

n) Price. 

7.3 Hardware Evaluation 

Further qualification of the system will relate to the 

following: 

a) Hardware resilience; 

b) Modern architecture; 

c) Number of concurrent terminals supported; 

d) Sufficient main store for the number of parts 
and structures being commonly used; 

e) Fast search capabilities; 

1) Sufficient mass storage; and 
g) Stage of its product life cycle. 

7.4 C'(Huiiiu»icatU)n Aspects 

Ihe functional specification will have indicated the 



other application areas of the business with which the 
production control system has to communicate and how 
the communication should take place, that is manual, 
batch interface or on-line. Batch and on-line facilities 
for communication with other hardware and software 
implies the need for local area networks utilizing the 
most prominent of the emerging standards. 
Communication between different vendors' hardware 
using third party software is often difficult and, therefore, 
expensive. If communication (especially on-line) is or 
will be important to the installation, compatible hardware 
and software should be chosen at the beginning where 
possible, to avoid major expense. 

7.5 Justification 

In order to justify the cost of any system, the present 
costs should be known, quantified and documented. 
Projections on cost savings from that point can then 
be made and verified when the time comes. One of the 
biggest mistakes made in the cost justification process 
is to fail to quantify the present costs. These costs 
should be identified in measurable terms and the same 
measures applied after implementation. Additionally, 
the benefits of the new system should be expressed in 
measurable terms which implies that before any 
implementation takes place it should be known what 
the benefits ought to be and how to measure them. 

8 IMPLEMENTATION 

8.1 General 

8.1.1 There are two phases in implementation. The first 
is the installation phase comprising the installation of 
hardware, software, communications and the accom- 
plishment of basic training to allow the new system to 
be certified ready for use. The second and far more 
difficult phase is the assimilation of the new system into 
the daily use and routine so that it becomes a valuable, 
effective and successful business investment. Planning 
for installation only will not provide the full benefit 
identified in the justification exercise. It should therefore 
be planned as the first step or major task in the overall 
implementation of the business system. Taking this long- 
term view keeps the installation phase in context, shows 
its relationship to future implementation activities and 
helps to prevent the loss of key people to the project at 
the finish of installation. 

8.1.2 However, the installation has to be successful 
and be seen to be successful to allow full 
implementation to take place. The installation step is 
described in detail in 8.2 to 8.5. 

8.2 Strategic Approach 

8.2.1 There are generally three ways lo install ihe 
software system. 
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a) Parallel run — This technique is used when 
an existing system is being replaced. The new 
and old systems are run in parallel during a 
specified change-over period to gain 
experience and confidence in the new system 
before the old one is removed. The drawback 
to this procedure is the problem of trying to 
keep two systems exactly aligned. If one is 
out of phase with the other then there is always 
the problem of which one is current and which 
one should be used. This can be twice the 
work for all people involved, both end users 
and data processing personnel; 

b) Slep-hy-step — This technique is used when 
portions of the business can be moved across 
lo the new system one part at a time. An 
example might be the installation of a central 
sales order processing system to replace a 
conglomeration of five or six different 
systems used at various factory locations. By 
moving the low volume sites across first and 
gaining confidence and experience, the large 
volume sites can covert later after greater 
knowledge and skill has been acquired. Also, 
since each site is being moved across 
sequentially by the same data processing 
team, both the end users and installation team 
can pace themselves to allow for 
unanticipated problems and learning curve; 
and 

c) Big hang — This technique is used when 
space and cost are paramount. The old system 
is removed and the new system installed and 
commissioned over a weekend, holiday or 

,shut down period. It is usually a high risk plan 
because failure of the new system to perform 
to the set standards directly impacts the 
business since there is no fall-back capability 
available. However, this may be the only 
alternative for new factories or green field 
sites. 

8.3 Project Team 

8.3.1 The project team should be managed by a 
dedicated manager from the production control 
function. His mission is to first establish the installation 
objectives in measurable terms, get proper project 
planning in place, agree proper resourcing, get an 
installation budget, establish the training requirement 
and training schedule, get all these points agreed by 
senior management, and then review progress and take 
appropriate action where necessary. 

8.3.2 To assist in this task the project manager will 
need project team members from several areas of the 
business as follows: 



a) End users of the production control 
department; 

b) Production control middle management; 

c) Data processing staff and middle 
management; 

d) Liaison members from sales/marketing, 
finance, manufacturing, distribution, and 
engineering; 

e) In-house or third party education and training 
instructors; 

f) Quality control; 

g) Technical authors; and 

h) Software/hardware vendor project manager. 

8.4 Project Control 

8.4.1 The objectives, timescales and co^ts for the 
installation have to be agreed with senior management 
at the outset. This requires the following items: 

a) An objectives sheet set out in measurable 
terms which will be used as benchmarks in 
the final audit; 

b) A budget for internal and external costs; and 

c) A fully documented project plan showing all 
the activities required and their dependencies, 
the time frame and resourcing (by name) for 
each activity and an achievable end date. 

8.4.2 Once these plans are agreed it is the job of the 
project manager to manage the Installation on a daily 
basis, with total dedication to the task by having all 
other responsibilities removed and reallocated to 
others. Without this level of commitment the project 
will not be seen to be important and will consequently 
not achieve its objectives. Project management requires 
periodic reviews at the working level, middle 
management level and senior management level. These 
reviews need to include the vendor project manager 
and all actions should be minuted and followed up. 

8.5 Education and Training 

8.5.1 One of the major activities to be identified and 
accomplished during installation is the training of all 
those involved. This should take place at three levels 
and the appropriate time, follow-up and budget should 
be allocated. The three levels are as follows: 

a) End user — This is where practical training 
of all end users takes place. It should contain 
an introduction from their senior 
management, an overview of the total 
implementation plan and objectives showing 
benefits, as well as extensive hands-on 
training sessions where all objections are 
handled, negative reactions neutralized and a 
clear understanding of the system gained; 
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b) Middle management — The emphasis here is 
on how the system works in support of their 
individual management tasks. It is both a 
selling and learning course with the emphasis 
on functional capability showing new/better 
techniques for doing the job; and 

c) Senior management — Th is shou Id be a short 
sharp selling course on how the system fits in 
and supports the other business systems, what 
the major benefits are, the return on 
investment expected and a demonstration of 
its major or most competitive functions. 

9 ON-GOING OPERATION OF COMPUTER 
AIDED PRODUCTION MAN AG EMENT (CAPM) 

9.1 General 

9.1.1 A well planned and executed implementation 
should mean that after project completion the new 
system will operate as planned for several months 
without adjustment. However, managers will be aware 
ihal business conditions change rapidly as well as staff, 
products and processes. It is, therefore, vital that ail 
aspects of the computer aided production management 
(CAPM) systems are regularly reviewed to ensure that 
they are continuing to meet the top level objectives of 
Ihe business, that forthcoming threats and opportunities 
are identified and that the appropriate actions are taken 
to minimize risk and maximize benefit. 

9.1.2 Because of the integrated nature of computer 
systems, each item of data in the system is used by 
several department and is open to enquiry by all. It is 
recommended, therefore, that at some operational 
meeting (typically the master schedule meeting, where 
most departments will be involved in agreeing the 
manufacturing contract for the coming periods), there 
should be a review of the top level business measures, 
that might include the following: 

a) Customer due-date performance (percentage 
of complete orders shipped within one day, 
early or late of plan); 

b) Percentage of warranty claims; 

c) Stock turns; 

d) Percentage of waste in factory (including 
yield, scrap, obsolescence, rework); and 

e) Profit against plan. 

9,1.3 Forthcoming challenges might include the 
following: 

a) Introduction of a new product; 

b) Introduction of a new machine or process; 

c) Major swing in product mix; 

d) Recruitment of a new staff member who will 
be a key user of the system; 



e) Promotion of existing staff to position^ where 
they will use new functions of the system; 

f) Planned software improvements; 

g) Planned hardware changes; and 
h) Possible power cuts. 

9.1.4 Any of these or similar types of potential 
problems or any significant deviation from the 
performance indicators should have a plan of action 
agreed as a matter of priority. 

9.1.5 There are a number of issues which affect the 
ongoing operation of any system. These will be 
examined in detail in 9.2 to 9.7. 

9.2 User Implications 

9.2.1 General 

CAPM systems are people-driven decision systems, 
supported by computer based information processing 
facilities. The ultimate factory-of-the-future operated 
entirely by computer and robot is a concept that is much 
talked of but has not yet been achieved in any but the 
simplest forms. Some of the most vital ingredients in 
the ongoing success of a total system are, therefore, 
the commitment and retraining of staff and their 
preparedness for continuous improvements towards 
just-in-time(JIT) manufacturing. 

9.2.2 User Commitment 

9.2.2.1 During implementation user commitment will 
have been a major task for the company management. 
The project communication links should be maintained, 
the focus being changed from the completion of 
activities to the attainment of business objectives. 
These should be the top level company objectives. The 
latter are likely to achieve false local optima only, for 
example, local productivity isonuses tend to generate 
output, not saleable throughput from the factory and 
measuring buyers by price variance leads to cheap 
buying but poor quality and delivery performance. 

9.2.2.2 These high level measures are less directly 
affected by individual effort, more by teamwork. The 
communication programme should therefore aim to 
generate the motivation to work as a team and create 
the understanding that the team is only as strong as its 
weakest link. 

9.2.2.3 If a bonus scheme is thought necessary then it 
should be linked into a high level measure, ideally 
annual profits. However, the communication 
programme should then spend more effort to create an 
understanding of the other market and financial factors 
that can have a major impact on the profit figure. 

9.2.2.4 The commitment demonstrated by the senior 
managers is critical. Nothing will destroy a well 
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planned and implemented production control system 
taster than a manager who wilfully ignores one of the 
policy rules that he has agreed. The master schedule 
establishes all other schedules in the factory and if a 
customer is so important that an order has to be pushed 
Ihrough, then top management should be seen to agree 
the new master schedule and the consequences on all 
other orders in the system. 

9.2.3 Uxcr Retraining 

9.2.3.1 Education and training are stressed as major 
success indicators in 8. It is therefore important that 
any new person coming into the company should be 
educated and trained to a similar standard. 

9.2.3.2 For people who are moved within the company 
the need for education and retraining is less obvious 
and more frequently omitted. It is important to realize 
that such a person's attitudes to his new role may have 
been formed before the introduction of the new system 
and that he will require the same education and training 
as any other new person to enable him to work with 
the team. 

9.2.3.3 As in 8, it is again important to stress the 
difference between education and training. 

a) Education involves generating awareness of 
the underlying principles that drive the 
system, understanding of the key policies 
which staff need to observe to run the system 
successfully and commitment to use the 
information to make decisions to maximize 
the company's benefit. 

b) Training involves instructing users of the 
system to follow the standard operating 
procedures and on the actions necessary when 
problems arise. 

9.2.3.4 The other key aspect of user retraining is that 
systems do not stand still; they evolve and develop. 
Changes and additions will be made to the computer 
and manual parts of the system. Likewise there will be 
changes in the company targets. For any major or minor 
change it is vital to educate and retrain the users directly 
involved and to ensur« that other staffs are kept 
informed. Examples of such change might be linking 
the sales order processing system with the 
manufacturing system or using an MRP H 
intplementation as the start of a JIT continuous 
improvement programme. 

9.3 Computer Operations 

9.3.1 Depending on the size of the system and its 
complexity, the operation of the system on a daily basis 
will require anything from minimal attention, that is 
start up and shut down, to dedicated data processing 



professionals devoted to the smooth operation of the 
whole information technology environment. 

9.3.2 For fault free operation, care has to be taken to 
have the correct levels of experienced personnel 
available especially during periods outside normal 
hours, that is nights and weekends. Such personnel 
should initially be trained by the hardware vendor as 
part of the installation project to ensure the adherence 
to good practice, especially in the areas of security, 
backup, archiving and maintenance. Alternatively there 
are firms that offer a computer operation service. 

9.4 Hardware Maintenance 

Hardware maintenance is usually contractually agreed 
with the vendor and provides for periodic preventative 
maintenance, optional advice, guidance and upgrade 
service, plus breakdown call-out service. The 
maintenance may be provided directly 1)y the vendor 
or through an authorized third party. 

9.5 Software Maintenance 

9.5.1 The arrangements for the maintenance of 
software are similar to those for the maintenance of 
hardware with the added complication of support for 
modifications if they have been applied. Maintenance 
of application software is an important consideration 
for all user companies for three main reasons. 

a) It should be appreciated that in any software 
of significant complexity there are likely to 
be logical inconsistencies (bugs). Despite 
exhaustive testing procedures some will be 
undiscovered and may cause erroneousresulis 
or even system failure (crash). 

b) Most vendors provide a general purpose 
software product with a range of inquiry and 
reporting capabilities. If, from this selection 
of screens and reports, the specific 
information needed for the business is not 
available or awkwardly presented, the 
decision may be made to modify the screens 
and reports to suit. Usually no extension to 
the normal maintenance agreement is needed 
in this case since only the output format is 
altered. Furthermore, as operating experience 
grows, the software vendor is likely to 
develop additional features and improved 
routines that will speed up processing and 
provide extra functions. New peripherals, 
communications or hardware requirements 
may also cause software modiUcations. 

c) As business requirements or trade regulations 
change, a user may find that extra functions 
are required and may decide for these or other 
reasons to modify the source code, either 
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using his own resources, those of the vendor 
or those of a third party. The extent to which 
this complicates support depends on whether 
the changes are driven by a single user or 
many users (a user group). When many users 
request an enhancement a software vendor 
will often develop the new facilities required. 
However, when the changes are driven by one 
user only maintenance will have to be 
carefully negotiated with the vendor since 
changes to the source code can render the 
software unusable or unsupportable if poorly 
done. Unless the changes can be covered by 
a bespoke enhancement arrangement, the 
vendor will only support the standard source 
code and let the user worry about supporting 
the changes. If the changes are extensive the 
vendor may no longer support any of the 
product except by such a special arrangement. 
In those cases, usually the party that 
undertook the modifications will also support 
them as part of the arrangement. Customizing, 
as it is called, should be done with reasonably 
advice and guidance from the owner of the 
software to allow the modifications to be 
easily included in any future upgrades of the 
software, the operating system, or the 
database management system. 

9.5.2 It follows from 9.5. 1 (a) to (c) that the agreement 
for software maintenance should be formal and 
contractual. It should normally be with the original 
vendor, but in some cases it can be with a reputable 
software house that is allowed access to the source 
code. User maintenance is not recommended without 
careful consideration of all the implications (it is 
estimated that 80 percent of data processing budgets 
are spent on maintenance). 

9.5.3 Software maintenance agreements typically cost 
1 percent to 1 5 percent of the software purchase price 
per annum. For this a user might expect the following 
services: 

a) A bug fixing service; 

b) A help desk for user application queries; 

c) Hotline support for operating problems; 

d) Free version updates with appropriate 
documentation; and 

e) Membership of a user group. 

9.5.4 The help desk and hotline services are normally 
during office hours and 24 h service would be an extra 
charge. A number of consultancy days per year may 
also be included, but are normally charged as extra. 

9.5.5 The vendor's version update policy should be 
clearly stated. Updates should be at regular but 



infrequent intervals, perhaps every 6, 9 or 12 months. 
They should be announced before hand with an 
indication of the new features and functionality, so that 
users can prepare for implementation. Old versions will 
not normally be supported for more than a few months 
after the new version is shipped. 

9.6 Contingency Planning 

In particularly sensitive environments, the best way to 
have 1 00 percent reliability is to run a duplicate backup 
system. Since this level of expense and contingency is 
not always necessary, normal planning calls for the 
following action: 

a) Backup copies of all work taken on a periodic 
basis depending on volume of work but 
usually at least once a day; 

b) Backup stored in a safe fireproof place usually 
outside the computer centre area and 
preferably in a security vault; and 

c) Emergency computer usage agreement with 
the vendor or other sftitable third party using 
the same equipment and configuration, 

9.7 Security 

9.7.1 All of the procedures described for contingency 
planning in 9.6 are also appropriate for the prevention 
of accidental loss of information. However, where 
deliberate tampering or possible theft of information 
is to be prevented, additional measures need to be 
taken, 

9.7.2 The possible tampering and theft by outsiders can 
be minimized by careful application of the security 
measures built into the computer operating system. If 
this is a requirement for the business when choosing 
the system it should be included in the list of essential 
requirements when evaluating the software and 
operating system. The security features operate in two 
ways, first, by setting functional parameters which only 
allow certain terminals to access certain information (for 
example only the personnel department can access salary 
information) and/or by setting certain terminals to 
respond only to queries and not allow input of data to 
prevent tampering; secondly, the opiating system can 
be set to allow access only by authorized individuals 
through the use of a password. This password when 
typed in will not appear on the screen to prevent 
unauthorized people seeing it and it should be 
periodically and conscientiously changed and protected. 

10 FUTURE TRENDS 

10.1 Computer Integrated Manufacturing (CtlVI) 
and the Information Systems Strategy 

10.1.1 In 4.1 it is stated that the strategies that have to 
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be in place, agreed and understood to drive a successful 
business are the marketing strategy, the business 
strategy and the information technology strategy. The 
evolution of the information technology strategy that 
is taking place for manufacturing companies today is 
an extension of the management information system 
(MIS) concept to include computer integrated 
manufacturing (CIM), The implementation of CIM 
cannot be done completely without the proper links 
into the other business functions such as finance, sales/ 
marketing, customer service, research and 
development and commercial/legal systems. 
Furthermore, there is a need to provide management 
level summarized and graphically displayed 
information to all senior management utilizing the 
same man/machine interface (MMI) capability. The 
trend is, therefore, for CIM to link together databases 
of information where each is servicing a major business 
discipline and utilize office systems to provide across 
the company MIS or senior management extracts from 
these communicating databases. 

10.1.2 The major stumbling blocks to the 
straightforward implementation of these concepts are 
as follows: 

a) Lack of agreed communication standards; and 

b) Lack of non-keyboard oriented input/ 
communication with the computer systems. 

10.1.3 As the pressure for reduced manufacturing 
development-to-delivery lead time, better quality and 
greater llexibility in product configuration continues 
(0 increase these barriers will be overcome. 

10.2 Hiirdware and Network Developments 

10.2.1 All signs in the industry point to computer 
hardware that will be smaller, cheaper, faster and better. 
The implication for the user is that capacity becomes 
less and less of a problem as the size and price come 
down and the reliability goes up. Also, cheaper and 
faster computers will start to be used in what were 
previously areas of marginal or very small return on 
investment simply because the cost has dropped. 

10.2.2 Probably the most significant trend in this 
scenario is distributed processing, the move away from 
large centralized databases on mainframes to 
distributed or departmental systems where all the 
business systems of the department are co-located on 
a departmental machine. The departmental applications 
then share data between departments using distributed 
databases interfaced to a network. There will be, 
therefore, duplicate information in the various 
departntents that is kept up to date and managed by a 
network community management system that 
incorporutc-s full security/access control mechanisms 



for proper data protection. 

10.2.3 It will be important in this environment to make 
sure that old and new systems can coexist and 
communicate in this network and that system 
exchanges and replacement will be transparent to the 
network and end users. To allow this to happen and in 
effect to have seamless connectivity between 
departments a new type of data integration should 
evolve. This process is known as the conceptual 
interface, where it is the business process, not the data, 
which is being networked. The process involves the 
interface and exchange of logically dependent rather 
than physically dependent information. The result 
should be an evolution of hardware and community 
management systems that can coexist with existing 
computer hardware and software developments and 
take advantage of new developments by non- 
disruptively introducing them into the network. 

10.2.4 Currently the biggest obstacle to communication 
between old and new systems is the lack of agreed 
communications standards. Users will soon want to 
share not only data between business units but al^so 
voice, text, image and potentially full motion video 
displays. Standards have not yet been established or 
agreed to allow this to happen. At present the Open 
Systems Interconnect (OSI) Standard is being defined 
by the International Organization for Standardization 
(ISO). Since it is vendor independent, the seven layer 
model of the OSI is popular, but even this requires the 
cooperation and agreement of vendors and users to both 
adhere to the standards and develop future products in 
line with the agreed approach. Until this happens, data 
processing and communications managers will have 
to anticipate and plan for an evolutionary move to the 
new services and facilities that are forthcoming. 

10.3 Software Developments 

10.3.1 The facility that will enable the community 
management and network systems, described in 10.2, 
to function will be the software environment. Software 
has been steadily evolving over the past 20 years from 
third generation to fourth generation and eventually 
fifth generation systems will be available. The 
difference between the three generations is important 
in understanding how the emphasis on capability has 
changed and also on how it will be possible for the 
three generations to coexist and complement each otiier 
in a future business environment. 

10.3.2 Third generation languages like COBOL and 
BASIC are very powerful but require an expert to use 
properly and derive full benefit in large complex 
database developments. The emphasis in the third 
generation has been on producing logical algorithms 
of functionality. 
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10.3.3 Fourth generation languages now concentrate 
more on providing a sensible framework and structure 
lor development. The emphasis has mov^d away from 
pure logical programming to ease of use and total 
system logic definition. The key fourth generation 
innovations have been as follows: 

a) Use of a data dictionary for defining logical 
relationships; 

b) Application tools for the rapid development 
of search and data manipulation capabilities; 

c) Report writers (report generators); 

d) Macro instruction writers for quick code 
writing of straightforward logic; and 

e) Relational database approaches. 

10.3.4 One imposition of the fourth generation 
approach has been to require full system design and 
dellnition before programming can begin. The total 
approach should be considered first rather than just 
the logic of an individual algorithm. 

10.3.5 The fifth generation systems are likely to adopt 
the theme of integration and facilitation. The ability 
to unlock information regardless of where it resides 
in the network and the ability to capture and apply 
expertise will be paramount. The fifth generation 
systems will probably be knowledge based 
capabilities becoming the facilitating gateways to the 
network. They will probably provide the following 
attributes: 

a) Sensible guided access to information; 

b) Well developed community management; 

c) Conceptual interfacing by finding the data in 
the network that are needed and then setting 
up the data processing requirements for 
moving data about and hence communicating 
on a logical basis; and 



d) Natural language questioning and touch 
screen input allowing non-structured access 
to data. 

10.3.6 All these developments will greatly enhance the 
ability of extant systems and applications to work 
together and achieve even greater return on the present 
investment. 

10.4 Expert Systems 

10.4.1 Expert systems that can be used for decision 
making in the manufacturing arena are evolving. 
Examples of their potential use are as follows. 

a) Configuration specification for the 
manufacture/assembly of standard purls and 
components to fulfil a complex customer 
requirement — In essence, it will be possible 
to take a request for tender and produce a 
proposal based on standard options with lead 
times and costs; 

b) Decision control on the shop-floor — An 
expert system will be available to cell 
controllers in an unmanned environment. If a 
problem occurs its symptoms could be fed 
automatically to an expert system to provide 
a solution or elevate the problem to the next 
level in the shop-floor control hierarchy for a 
similar deliberation at that level and upwards 
if required until a solution is found and 
automatic rescheduling takes place; and 

c) Master scheduling modeller — This will 
create a model for master scheduling or 
factory scheduling using four variables: 

1 ) Forecast; 

2) Actual sales; 

3) Actual and forecasted capacity; and 

4) Cost. 
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ANNEX A 

(Foreword) 

DEVELOPMENT OF THE USE OF COMPUTERS IN PRODUCTION CONTROL 



A- 1 GENERAL 

A-I.l Soon after the advent of electronic computers it 
became apparent that they would have a potential role 
in production control. In common with many other 
applications predicted at that time there were many 
obstacles to be overcome before most ideas became 
practical. In particular it can be seen with hindsight 
that workers were over optimistic about the data 
processing capacity and reliability of the early 
computers, tried to apply erroneous theoretical logic 
in some areas, did not involve users and failed to 
identify that the real benefits would come from 
integrulion of the information held within the system. 

A- 1. 2 II is therefore useful to look briefly at the history 
of the development of computers so that we may 
understand where certain ideas and concepts have 
come IVom and avoid repeating the early errors. 

A-2 COMPUTERS AS CALCULATORS 

A-2.1 Mathematics Laboratories 

Tlie early valve based computers, which were able to 
perform mathematical calculations rapidly albeit with 
very small core memory and limited input/output 
devices, were chiefly used in mathematics laboratories. 

A-2.2 Operational Research (OR) 

A-2.2.1 With the advent of transistors, larger memories, 
card input, magnetic tape input and output plus slow 
line printers, the processing of small volumes of data 
became pos^sible. 

A-2. 2. 2 At this time operational research (OR) 
activities were focused on the problems of production 
and had developed formulae to express economic order 
quantity (EOQ). They had also identified forecasting 
tools based on history that predicted future trends and 
seasonality. 

A-2.2. 3 In addition, they were able to estimate the 
likelihood of deviation from forecast by calculating 
standard deviation or mean absolute deviation (MAD). 
This led to the concept of customer service levels which 
could be maintained by holding safety stock (SS) to 
guard against unexpected demand. 

A-2. 2.4 The new computers made these calculations 
easy and fast to perform and before long it was common 
to find factories with manual reorder point (ROP) logic 
systems based on EOQ, SS and lead time calculated 
by computer on a periodic basis. 



A-2. 2. 5 At the same time Forrester was using 
computers to carry out time scries evaluation or 
simulations of the likely effect of interdependency. 
These showed that the dynamics of the situation would 
not lead to the optimum use of stock as predicted by 
the OR workers. This work was largely ignored and 
production control departments were thus busy 
launching economic orders at the reorder point and 
even more busy expediting the shortages of stock in 
order to complete jobs. 

A-3 COMPUTERS AS BATCH PROCESSORS 

A-3.I Inventory Recording by Batch Updates 

A-3.1.1 With the development of larger memory 
computers that could store information on random 
access disc packs it became possible to maintain the 
stock level by a series of daily or weekly batch updates 
of the movements of parts into and out of store. 

A-3. 1.2 In general this was accounting department and 
computer systems department driven and required 
users to dispose of their trusty, ever accessible, card 
index systems, for which they had responsibility and 
accountability and users were instructed then lo rely 
on periodic reports detailing order launches and stocks 
that were difficult to understand and reconcile. The 
users' reactions were mostly negative, resulting in 
inaccurate cut-off points, continued expediting and the 
establishment of three stock figures: 

a) A gross value maintained by accounts; 

b) A theoretical figure from the computer; 

c) A card index system of stock control 
maintained by the stores. 

A-3. 1.3 The main effect of these inventory/ROP 
systems was that calculations based on incorrect data 
and incorrect logic were performed faster. This resulted 
in confused and frustrated staff (who blamed the 
computer), together with higher stocks and poorer 
service levels. 

A-3.2 Net, Dependent, Time Phased, Supply and 
Demand 

A-3.2. 1 In 1969 Orlicky published his seminal work 
on materials requirement planning (MRP). This 
identified the key fault in ROP systems, namely that 
they did not take into account the dependent demand 
that exists between a product and the components that 
it is made of, both in the required quantity and timing. 
For components that were not sold outside the system 
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it was therefore not necessary to forecast the demand. 
This could be accurately predicted by multiplying the 
component quantity per product from the bill of 
materials (BOM) by the forecast sale of the product 
and backdating its requirement by the lead time 
necessary to build the components into the product. 
These requirements for the product were, in addition, 
netted off against any product in stock and any product 
expected from a supply order already issued. This is 
in fact the real logic of the shortage list and it therefore 
offered a system that users could understand and use 
more effectively. 

A-3.2.2 In fact, the limited computing capacity of the 
era meant that suggested actions could not be 
recalculated frequently enough to take into account 
changes occurring in the factory and were still 
bedevilled by the difficulty of maintaining a high 
accuracy level of stock, BOM and routeing data. 
Another problem was that the majority of systems were 
developed as bespoke systems. This slowed their 
introduction but also tended to incorporate false logic 
due to poor systems analysis, a misunderstanding of 
the real needs of the business or the belief that special 
circumstances applied for each company. One specific 
area of debate was the scheduling technique and 
capacity assumption. In a well ordered production 
system it seemed attractive to schedule on a finite 
capacity basis. However, apart from project type 
applications, production is not determinate, but highly 
variable (as is demonstrated when a manager decides 
to rush a particular order through quickly). These points 
undermine the finite capacity assumption in all but 
simple process applications. 

A-3.3 On-line Enquiry Systems 

A'3.3.1 Until this stage all usable data had to come 
from the computer as printed paper (printouts). As 
computers increased in size and power it became 
possible to attach visual display units (VDUs) to the 
host computer. This enabled stores, production, 
inventory, control personnel to enquire on stock and 
work order information. The system was still batch 
updated so the information was still only correct at the 
time of update, but because transaction history data 
were made available it now became feasible to maintain 
accurate stock data. 

A-3.3.2 However, the recalculation of order dates and 
quantities was still a lengthy process, forcing users to 
rely on weekly or, more usually, monthly planning 
runs. In addition, applications were not usually 
integrated so that data input to the system was often 
duplicated with increased probability of error and 
reconciliation ditficulties. System power also limited 
ihe number of terminals that could be attached, thus 
restricting the accessibility of information. 



A-3.3.3 Nevertheless, there were many successful MRP 
implementations, particularly where stable forecasts 
or order patterns made resource management easy to 
tackle. 

A-4 COMPUTERS AS ON-LINE INFORMATION 
SYSTEMS 

A-4. 1 On-line Teleprocessing and Net Change 
Planning 

A-4.1.1 With regular order of magnitude improvements 
in the size of computer memory, the speed of 
processing and the amount of secondary disc storage 
available, it became possible to cater for on-line 
transaction processing. This feature meant that at last 
users could have their card index information available 
on demand. Many of the reasons for inaccurate stock 
balances had thus been eliminated and, with their 
increasing number of terminals connected to die 
system, other departments shared that up-to-date 
accurate information. This policing effect could now 
encourage the maintenance of data accuracy. 

A-4.1.2 The software development of net change 
planning has significantly reduced the suggested action 
output. Previously it was necessary to regenerate action 
messages for every part. Now, it is possible to replan 
only those parts where a change has occurred in the 
supply, demand or static data. This not only reduces 
output but also processing time so that overnight net 
change calculations are now a realistic opportunity for 
ail well sized and operated systems. 

A-4.2 Modular System Integration 

A-4. 2.1 Increasingly it has become accepted that 
management and control of production can be thought 
of as a number of standard modules. A list of the main 
modules might include the following: 

a) Engineering data (formulations or recipes); 

b) Inventory control; 

c) MRP; 

d) Purchase order control; 

e) Works order control; 

f) Capacity control; 

g) Master scheduling; 

h) Resource requirement planning; 
j) Cost control. 

A-4. 2. 2 Most manufacturing companies aim to 
encompass these facilities within their manufacturing 
resource planning (MRP 11) system, the key concept 
behind this system being the rapid feedback of changes 
and problems to ensure the maintenance of accurate data 
and a valid set of priorities. More and more companies 
are now prepared to buy standard packages that provide 
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ihe major functions and where necessary incorporate 
specific needs of their business by tailoring the standard 
programming code. Frequently it is only necessary to 
make the input and output suit their users needs. 

A-4.2 J The reliability and speed of modern computers 
and software means that at last users can pursue their 
different activities on the basis of a common set of 
accurate figures and valid priorities upon which they 
can make sound decisions. They are controlling the 
system, rather than being controlled by it. 

A-4.3 Further Integration 

A-4.3. 1 Naturally some businesses have found it 
necessary to integrate in other directions. Computer 
systems can now offer a wealth of optional extras such 
as the following: 



a) 

b) 
c) 



d) 



Distributed processing for multi-site 
operations; 

Automated shop-floor data collection; 
Repetitive or rate based planning for 
companies in high volume non-batch 
processing frequently found in just- in-time 
(JIT) volume manufacture; 
Computer aided design (CAD), computer 
aided manufacturing (CAM), computer aided 
process planning (CAPP) can now be linked 
and feed the main part (BOM), routeings and 
tool information needed to plan new or 
modified parts and products; 



e) Electronic data interchange (EDI) with 
suppliers and customers; and 

f) Materials handling through automated guided 
vehicles (AGV) and automatic storage and 
retrieval systems (AS/RS). 

A-4.3.2 However, as each of these and many other 
advances become possible in a technical sense it is vital 
that their use provides the opportunity for a genuine 
improvement in business performance. In addition, it 
should be recognized that the totally automated factory 
is still a dream of the future in all but the simplest cases. 
The variety and speed of change together with the range 
of options for correcting factory plans means that 
people continue to be the key ingredient for a successful 
manufacturing organization. JIT manufacturing is 
tending to reduce the necessity for detailed shop- floor 
control. This is better left to the managers and 
supervisors who can quickly react to problems as they 
occur in the most flexible and appropriate manner, 
secure in the knowledge that the data they are acting 
on is accurate, is the same as that being used by other 
parts of the organization and that they understand the 
logic that led to any suggested actions the system may 
output. 

A-4.3. 3 The trend of modern computer aided 
production control systems is in fact to give people 
both the time and information they require to do their 
real jobs, that is maintaining the competitive 
manufacturing edge of the business. 
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ANNEX B 

(Clauses 5. 1.5, 5.3.1 and 53.3) 

PRODUCTION AND INVENTORY CONTROL SOFTWARE 



B-1 The major package modules and software are listed 
in Table 1 . 

B-2 Modules may also be available for the following 
special applications: 

a) Business planning; 

b) Lot traceability; 

c) Contract management; 

d) Estimating; 

e) Tool management; 

f) Engineering change control; 

g) Distribution requirement planning; 

h) Shop floor data collection and monitoring; 

j) Forecasting; 

k) CAD/CAM; 

m) CAPP; 

n) Direct numerical control (DNC); 



p) Statistical process control; 

q) Finite capacity scheduling; 

r) Maintenance management; 

s) Automated warehousing; 

t) Technical records; 

u) Process control; 

v) Project management; and 

w) Finite element analysis. 

B-3 Other modules may be available for the following 
non-manufacturing activities: 

a) General ledger; 

b) Sales ledger; 

c) Purchase ledger; 

d) Fixed assets; 

e) Sales order planning; 

f) Sales analysis and forecasting; and 

g) Payroll. 



Table 1 Standard Modules and Functions 

(Clause B- 1) 



SI 


Module 


Functions 


No. 






(1) 


(2) 


(3) 



Technical data 



Basic item data 

Bill of material structure 

Bill of task structure 

Copy product structure 

Item where used enquiry 

Technical change control 

Reports by single level, multi-level, summarized explosion 

Archive change history 



ii) Inventory control 



Goods in receipt 

Works order material issue by item, kit, backftush 

Rate schedule backflush 

Issue to floor stock 

Trial kitting 

Subcontract material issue and receipt 

Works order product receipt 

Customer order shipment 

Unplanned inventory movement 

Multi-location stock record 

Transaction history 

ABC analysis 

Cyclical inventory count 

Stock quantity on-hand enquiry 

Customer stock order entry 

Customer special order entry 

Customer order enquiry 

Works order entry 

Works order shortage check 

Works order enquiry 
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Table 1 (Continued) 



SI 

No. 

(1) 



Module 



(2) 



Functions 



(3) 



Supply/demand review 
Forecasting non-MRP items 
Order status listing 
Shortage reporting 
Archive transaction history 
4GL report generator 



iii) Material requirements planning (MRP) 



Planner action report 

Suggestions on screen 

Supply/demand review with MRP sugigestions on screen 

Time phased pegged report 

Bucketed report 

Regenerative or net change review 

Parameter control of filters, horizons, run type 



iv) 



Manufacturing technical data 



Work centre data 

Routeing data, primary, alternative, customized 

Copy routeing data 

Tool data 

Process-tool link data 

Work centre report 

Work centre where used report 

Process where used report 

Routeing report 

Process report 

Tool where used report 



v) Shop floor control 



Scheduled routeings maintenance 

Reschedule orders 

Scheduled routeing report 

Split batch maintenance 

Output recording by works order or rate schedule 

Scrap recording 

Rework recording 

Labour reporting 

WIP status reports 

Manufacturing activity reports 

Labour performance reports 

Scrap reports 

Archive manufacturing activity 



vi) Capacity requirements planning (CRP) 



Capacity requirements summary 
Capacity requirements detail 



vii) Master production scheduling (MPS) 



Family structure data 

Copy family structure data 

Family forecast data 

Explode family forecast to products 

Resource data 

Master schedule routeing data 

Copy master schedule routeing data 

Resource reports 

Master schedule routeing report 

Resource 'where used' report 

Master schedule item "where used' report 

Master schedule family structure report 

Family forecast report 

Available to promise 



viii) Rough-cut capacity planning (RCCP) 



Resource requirements summary 

Resource requirements detail 

What if simulation 

Summary resource and routeing maintenance 

Resource requirements valuation 



{Continued from second cover) 



1) PROGRAMMING 
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Fig. 1 Stages of Production Control 
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